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(57) An arrangement and a computer program prod- 
uct, for providing seamless IP mobility across a security 
boundary between two domains, secure domain (1 05) 
and insecure domain (107), is described. The invention 
comprises a novel architecture of known network infra- 
structure components, inner system home agent (130) 
and outer system home agent (1 02) along with enabling 
client software on the user device (103). The specific 
client software as well as the novel architecture repre- 
sents the invention. Unlike state-of-art today, the meth- 
od is based on the combined use of independent IP mo- 
bility systems in each of the two domains. The key to 
the invention is client software being able to operate with 
both mobility systems simultaneously. Moreover, com- 
munication takes place in such a way that the ordinary 
remote access security solution is in control of all access 
to the secure home domain of the user. The resulting 
method provides secure and seamless IPmobility In any 
domain with independent choice of mobility and security 
technologies. The invention does not require any signif- 
icant changes (adaptations nor extensions) to any IP 
mobility or security technology beyond existing or up- 
coming standards. Nor does it require any significant 
changes to existing infrastructure components. The mo- 
bility client software is the only component that is affect- 
ed, thus making the method client-centric, as opposed 
to a network-centric approach that is otherwise the al- 
ternative. The invention applies both for the current IPv4 
family of standards as well as the forthcoming I Pv6 fam- 
ily of standards. The Invention applies in particular for 
the Mobile IP and IPSec VPN standards but is not re- 


stricted to these technologies. The invention is applica- 
ble for any IP mobility and IP security protocols as long 
as they are based on the same set of underlying princi- 
ples. 
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Description 

[0001 ] The present invention relates to the field of IP 
mobility across a security boundary between domains. 
In particular, the present invention relates to a novel ar- 
chitecture of known network infrastructure components 
along with enabling client software on a user device. 

Background and terminology 

[0002] The large family of IP protocols constitutes the 
foundation for the development of the Internet. Today 
the Internet is based on version 4 of the protocol family 
(IPv4. In the future it expected to gradually be replaced 
by version 6 of the protocol family (IPv6. 
[0003] I P mobility is an enhancement that has gain in- 
terest in recent years. Different IP mobility protocol pro- 
posals exist both for IPv4 and IPv6. Making the Internet 
mobile has obvious advantages compared to the legacy 
mobile networks that are tailored for voice communica- 
tion only. Seamless IP mobility refers to the case when 
the user application is transparent to network changes. 
This is in contrast to ordinary IP when the application 
session breaks if the user changes his point of attach- 
ment to the network. The predominant IP mobility tech- 
nology today is Mobile IP [6, 13] that exists both for ver- 
sion 4 and version 6. 

[0004] The key parts of a Mobile IP system are Mobile 
IP client software on the user terminal and a Mobile IP 
Home Agent (HA) in the network infrastructure. The ter- 
minal with the client software is commonly referred to 
as a Mobile Node (MN). The home agent controls the 
topological correct address of the mobile node (called 
home address) and maintains a binding list with the cur- 
rent location of a mobile node (called care-of-ad dress). 
The mobile node signals to the home agent its current 
care-of-address. This happens either directly, or option- 
ally via an intermediate Foreign Agent (FA) if one exists 
in the local environment. The home agent sets up a for- 
ward tunnel to redirect traffic from the topologically cor- 
rect home address to the current care-of-address. The 
tunnel arises from packet encapsulation performed by 
the home agent. For reference, any non-mobile host is 
referred to as a Correspondent Node (CN). 
[0005] Seamless IP mobility finds its most important 
application together with remote access IP security so- 
lutions like IPSec VPN [7]. A remote access VPN solu- 
tion consists of a VPN client on the user terminal and a 
VPN gateway (VPNGW) in the infrastructure. 
[0006] Together the VPN client and gateway employ 
both tunneling and encryption to maintain communica- 
tion from a secure domain to a terminal that is remotely 
connected from an insecure location in a different do- 
main. The VPN solution is usually the only way to reach 
components inside the secure domain. 
[0007] State-of-art today is to leverage on the version 
4 protocol family used on the Internet and to combine 
Mobile IP with IPSec VPN, thus facilitating the first gen- 


eration architecture for seamless and secure I P mobility. 
The most prominent application is the enterprise envi- 
ronment in which the intranet represents the secure do- 
main and the Internet represents the insecure domain. 

5 The potential of this combination is great since it gives 
nomadic workers less hassle and increased productivity 
as they are on the road. The most challenging part of 
the combined architecture is to maintain seamless op- 
eration also across the security boundary between the 

10 enterprise and the outside world. Any application started 
by a user while on the intranet should survive as the us- 
ers moves outside. At the same time, the VPN solution 
must be employed while outside. Inside the secure do- 
main the VPN solution should be turned off. 

15 [0008] U.S. patent application publication no. 
US2002/01 94386 discloses a "single mobility" Mobile IP 
client arrangement implementation providing a method 
for mobile IP nodes, wherein an IP application of the mo- 
bile node accesses the heterogenous network via a vir- 

20 tual IP network interface generated in the mobile node, 
thus allowing switching between different network acc- 
sess interfaces while an IP application via a single mo- 
bile IP node, e.g. a home agent, is running. However, 
the disclosure is not concerned with the problem of pro- 

25 viding seamless mobility for a mobile node on the move 
between different networks, and indeed not with the 
problems experienced when boundaries between such 
networks represent obstacles for transfer of mobility in- 
formation. 

30 [0009] The "Internet Draft" document n <draft-adrangi- 
nobileip-natvpn-tarversal-01> M by Farid Adrangi and 
Prakash Iyer, addresses the problem of providing seam- 
less IP mobility with traversal across VPN or NAT and 
VPN gateways by introducing a "mobile IP proxy". The 

35 "MIP proxy"is connected to and operates in a depend- 
ency relationship with home agent located behind the 
firewall in the enterprise network, and represents there- 
by another customised solution all the way from the mo- 
bile terminal through to the home agent. Accordingly, the 

40 "mobile proxy" disclosure does not represent a solution 
to the problem of providing full seamless mobility to the 
mobile user wishing to make use of services provided 
in the enterprise network as well as services provided 
by a network external to the enterprise network. By the 

45 H MlP proxy" solution, a separate mobility arrangement 
must be established in order to provide mobile access 
also to services provided by the network situated out- 
side the enterprise network. 

so Brief description of the invention 

[0010] The present application describes a novel ar- 
chitecture together with corresponding client software 
that can be used to solve the problem of seamless IP 
55 mobility across security boundaries. The proposed 
method is more general and has better characteristics 
than currently known alternatives. 
[0011] In this documentthe term architecture is used 
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to denote a combined structure that comprises both a 
Mobile IP part and a VPN part. The Mobile IP part in 
itself is referred to as a system. The VPN part is in con- 
trast refer to as a solution. This is for clarity only. These 
terms could have been used interchangeably. 
[0012] A VPN solution and a Mobile IP system both 
require client software on the mobile node. The term cli- 
ent software is generally used if the specific meaning is 
clear from the context. Otherwise the qualifiers "mobili- 
ty" and "security" are added to distinguish the client soft- 
ware parts. 

[0013] In a first aspect, the present invention provides 
an arrangement in a mobil data communications termi- 
nal (1 03) for providing mobil IP communication via a du- 
al tunnell IP packet data connection between a first ap- 
plication (121) in the mobil data communications termi- 
nal and a second application (1 01) in a second terminal 
in communication with an inner network (1 05), said inner 
network directly or via a firewall (104) connected with 
an outer network (1 07), wherein an outer mobil IP home 
agent (1 02) Is arranged in the outer network or in a DMZ 
(106) associated with the firewall and an inner mobil IP 
home agent (130) is arranged in the inner netwotk, said 
arrangement comprising: 

a first mobil IP client part (116) configurable for as- 
sociation with the inner mobil IP home agent (130), 
said first mobil IP client part arranged to convey da- 
ta between the first application and the second mo- 
bil IP client part and to an inner tunnell part (123) 
directed to the inner home agent, and 
a second mobil IP client part (115) configurable for 
association with the outer mobil IP home agent 
(102), said second mobil IP client part arranged to 
convey data between the first mobil IP client part 
and the outer network and to an outer tunnell part 
(124) directed to the outer home agent. 

[0014] In a second aspect, the present invention pro- 
vides an rrangement, wherein said second mobil IP cli- 
ent part further is configurable to also convey data be- 
tween the first application and the outer network, and 
said arrangement further comprising a device which, if 
the terminal obtains access via the outer network, is ar- 
ranged to provide a first connection between the first ap- 
plication and the first mobil IP client part, a second con- 
nection between the first mobil IP client part and the sec- 
ond mobil IP client part, and a third connection between 
the second mobil IP client part and the outer mobile IP 
home agent, and 

if the terminal obtains access via the inner network, is 
arranged to provide a fourth connection between the 
first application and the second mobil IP client part, and 
a fifth connection between the second mobil IP client 
part and the inner mobile IP home agent. 
[0015] In a third aspect, the present invention pro- 
vides an arrangement, wherein said first mobil IP client 
part (116) is controllable for activation or deactivation, 


and said arrangement further comprising a mobil IP de- 
tection device: 

a. said mobil I P detection device adapted to activate 
5 the first mobil IP client part on detection of a con- 
nection to the inner network (1 05) and a successful! 
mobil IP registration with the inner home agent 
(130), and 

b. saidmobil IP detection device adapted to activate 
10 the second mobil IP client part on detection of a con- 
nection to the outer network (1 07) and a successfull 
mobil IP registration with the outer home agent 
(130). 

15 [0016] In a fourth aspect, the present invention pro- 
vides an arrangement, wherein said first mobil IP client 
part (116) is controllable for activation and deactivation, 
and that the arrangement further comprises a mobil IP 
detection device arranged to activate the first mobil IP 

20 client part on detection of connection to the outer net- 
work (1 07) by means of at least one of a detection device 
selected from a group comprising: 

a. a first monitoring device arranged to determine 
25 the source IP address of an incoming packet and to 

determine that the address is outside an address 
range configured for the inner network (105), 

b. a second monitoring device arranged to analyze 
ICMP control messages and arranged to determine 

30 that an address associated with the ICMP control 
message is outside an address range configured for 
the inner network (105), 

c. a third monitoring device arranged to detect an 
outer home agent (1 02) on transmission of a regis- 

35 tration message with improper security association, 
and 

d. a fourth monitoring device arranged to compare 
results from said first and second monitoring devic- 
es with collected history regarding MAC and IP ad- 

40 dresses to Mobil IP Foreign Agents, Default gate- 
ways, and WLAN access points that indicate that 
the mobil terminal is operating in the outer network, 
and 

45 wherein at least one of said detection devices (a, 
b,c,d) is arranged to indicate that the mobil terminal 
(1 03) is connected to the outer network. 
[0017] In a fifth aspect, the present invention provides 
an arrangement, wherein 

so said first mobil IP client part (1 1 6) is controllable for de- 
activation, and 

said arrangement further comprising a mobil IP detec- 
tion device arranged for deactivating the first mobil IP 
client part on detection of a connection to the outer net- 
55 work (1 07) by means of at least one of a detection device 
selected from: 

a. a first monitoring device arranged to determine 
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the source IP address of an incoming packet and 
arranged for detecting that the address is inside an 
address range figured for the inner network (105), 

b. a second monitoring device arranged to analyze 
ICMP contrail messages and arranged to detect 
that an address associated with the ICMP control! 
message is inside an address range configured for 
the inner network (105), 

c. a third monitoring device arranged to detect an 
inner home agent (1 30) on transmission of a regis- 
tration message with incorrect security association, 
and 

d. a fourth monitoring device arranged to detect in- 
consistences in results from the first, the second 
and the third monitoring devices and collected his- 
tory regarding MAC and IP addresses to Mobil IP 
Foreign Agents, Default Gateways, and WLAN ac- 
cess points that indicate that the mobil terminal is 
operating in the inner network (105), and 

wherein at least one of said detection devices (a,b,c,d) 
is arranged to indicate that the mobil terminal (103) is 
connected to the inner network. 
[0018] In a sixth aspect, the present invention pro- 
vides an arrangement, wherein said arrangement fur- 
ther comprises, 

a third security client part interposed between the first 
and second mobil IP client parts and configurable for via 
a security arrangement arranged between said inner 
and outer networks establishing a secure connection 
with the inner network. 

[001 9] Furthermore, the present invention provides a 
mobil IP terminal, wherein said mobil IP terminal com- 
prises an arrangement according to any one of the 
aforementioned aspects of the invention. 
[0020] Furthermore, the present invention provides a 
computer program product comprising a data carrier 
having thereon a computer program code loadable and 
executable in a mobil IP data communications terminal, 
wherein said computer program code when loaded and 
executed in the mobil IP data communications terminal 
effects the establishment of an arrangement as recited 
in any one of the aforementioned aspects. 
[0021] Furthermore, the present invention provides 
an information technology (IT) system for providing a 
packet data connection between a first application (121) 
operable in a mobil data communications terminal (1 03) 
and a second application (1 01 ) operable in a second ter- 
minal in an inner network (105) protected by a firewall 
(104), said system arranged for communication by 
means of mobil IP with a system comprising the inner 
network, an outer network (107) and an outer home 
agent (102) arranged in the outer network or in a DMZ 
(1 06) associated with the firewall arranged between the 
inner and outer network, wherein: 


said inner home agent is configurable for associa- 
tion with a first mobil IP client part (11 6) operable in 
the mobil data communications terminal, and said 
outer home agent is configurable for association 

5 with a second mobil IP client part (115) operable in 
the mobil data communications terminal, 
said first mobil IP client part being arranged to con- 
vey data between said first application and said oth- 
er mobil IP client part and to an inner tunnell part 

10 (123) directed to the Inner home agent, and 

said second mobil IP client part being arranged to 
convey data between said first mobil IP client part 
and said outer network and to an outer tunnell part 
(124) directed to said outer home agent. 

15 

[0022] Furthermore, the present invention provides a 
data communications system for providing a packet da- 
ta connection between a first application operable in a 
mobil data communications terminal (1 03) and a second 

20 application (1 01 ) operable in a second terminal connect- 
ed to an inner network (105) protected by a firewall 
(104), said system arranged for communication by 
means of mobil IP via a system comprising the inner net- 
work, an outer network (107) and an outer home agent 

25 (1 02) arranged in said outer network or in a DMZ (1 06) 
associated with the firewall (104) being arranged be- 
tween the inner and outer networks, wherein: 

an inner home agent (130) is arranged in the inner 
30 network, and 

said mobil data communications terminal including: 

a. a first mobil IP client part (116) configurable 
for association with said inner mobil IP home 

35 agent (130), said first mobil IP client part ar- 

ranged to convey data between said first appli- 
cation and said second mobil IP client part and 
to an inner tunnell part (123) directed to said 
inner home agent, and 

40 b. a second mobil IP client part (11 5) configura- 

ble for association with said outer mobil IP 
home agent (102), said second mobil IP client 
part being arranged to convey data between 
said first mobil IP client part and said outer net- 

45 work and to an outer tunnell part (1 24) directed 

to said outer home agent. 

Detailed descripton and embodiments of the invention. 

so [0023] State-of-art architectures and their associated 
features will now be explained in conjunction with ac- 
companying figures depicting prior art, wherein: 

fig. 1 is a schematic representation example of a 
55 prior art Mobile IP system, 


an inner home agent (1 30) is arranged in the inner fig. 2 is a schematic representation another exam- 

network, and P |e of a prior art Mobile IP system, 
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fig.3 is a schematic representation another example 
of a prior art Mobile IP system, 

fig. 4 is a schematic representation another exam- 
ple of a prior art Mobile IP system, 

fig. 5 is a schematic layer model representation of 
an example of a prior art client and network adapter 
arrangement in a Mobile IP data terminal, and 

fig. 6 is a schematic layer model representation of 
another example of a prior art client and network 
adapter arrangement in a Mobile IP data terminal. 

[0024] As suggested by figure 1 and figure 2 there are 
basically two opposite ways of deploying a Mobile IP 
system together with a VPN solution to realize a com- 
bined architecture. Both architectures are well known to 
the standardization bodies [1] as well as in the industry 
in general [3,4,5]. The starting point is in either case a 
secure domain 105 separated from an insecure domain 
1 07 by a security gateway 1 04. The gateway defines the 
boundary between the domains and the inside corre- 
sponds to the secure side. For simplicity the reader may 
think of an enterprise network (secure inside domain) 
connected to the Internet (insecure outside domain). 
The secure domain comprises one or more IP networks 
under the same administrative control. The secure do- 
main is also referred to as the home domain of associ- 
ated users. The insecure domain comprises IP networks 
that are controlled by different administrative entities. 
The security gateway (aka: firewall) is responsible for 
packet filtering as wel! as remote access to the secure 
domain from outside. Gray shading is used throughout 
this document to signify a secure domain with its con- 
stituent components. 

[0025] Infigure 1 the Mobile IP home agent 102 is lo- 
cated outside the secure domain, eg. in the de-milita- 
rized zone 106 of an enterprise environment. The Mo- 
bile IP system does In this case operate outside to the 
secure domain and its role is to mobilize the VPN solu- 
tion. The system offers a fixed address for the VPN tun- 
nel end-point, thus the VPN tunnel survives any network 
change made by the mobile node 103. The encrypted 
VPN packets are carried as payload in the Mobile IP sys- 
tem and the VPN solution is referred to as overlaid. This 
Is illustrated in figure 1 by the VPN tunnel 123 being em- 
braced by the Mobile IP tunnel 124. The native traffic 
125 destined for the corresponding node 101 on the in- 
side becomes apparent in the secure domain after de- 
capsulation from the VPN tunnel. The Mobile IP compo- 
nents 102 and 103 are in this case drawn in a hatched 
gray/white pattern to signify that these components are 
associated with the secure domain (gray) but are other- 
wise operating in an insecure environment (white). 
[0026] I n figure 2 the home agent 1 02 is located inside 
the secure domain 105. The Mobile IP system does in 
this case operate on the inside and can only be reached 


from outside overthe VPN solution, thus the home agent 
is drawn in a solid gray color. The VPN tunnel 123 does 
now embrace the Mobile IP tunnel 124, corresponding 
to the opposite sequence of figure 1 . 

5 [0027] The architecture shown in figure 2 suffers from 
the fact that the remote VPN tunnel end-point at the mo- 
bile node 103 will change at every network change. Ac- 
cordingly, the VPN tunnel 123 needs to be re-estab- 
lished at every handover. This will in turn require re-es- 

10 tablishment also of the Mobile IP tunnel. On the other 
hand, there are some disadvantages also with the ar- 
chitecture shown in figure 1 . First, since the home agent 
1 02 is deployed on the outside the home address of the 
mobile does not belong to the secure domain 1 05. Con- 

15 sequently, the user must use his VPN solution from ail 
locations, also when he is inside his otherwise secure 
home domain. For the same reason, when the mobile 
node is inside the secure domain traffic to any other cor- 
responding node 101 on the inside will loop via the out- 

20 side home agent 1 02. Both effects are unfortunate since 
they impose a performance penalty. Finally, there is a 
potential security risk since the home agent 102 needs 
to set up dynamic forwarding tunnels through the firewall 
1 04 to arbitrary mobile nodes inside the secure domain. 

25 Normally, a tunnel through a firewall is allowed only if 
both end-points are static and if the traffic through the 
tunnel is subject to encryption both ways. 
[0028] To overcome the disadvantages just men- 
tioned it is possible to make hybrid architectures that 

30 combine the characteristics from figure 1 and 2. Figure 
3 and figure 4 illustrates two different approaches. The 
architecture shown in figure 3 is at the core of some ven- 
dor-specific offerings available in the industry [4,5]. At 
the time of this writing the architecture shown in figure 

35 4 is proposed for standardization to facilitate multi-ven- 
dor implementations [2]. Realizations of the architecture 
in figure 4 are currently not available from any vendor 
but are expected to become available in the nearf uture. 
[0029] In figure 3 the home agent 102 and the VPN 

40 gateway 104 are implemented in a single-box. The 
home agent is in this case drawn partly in solid gray and 
partly in a hatched pattern to indicate that it belongs to 
the secure domain yet at the same time it is accessible 
from outside without using the VPN solution. The oper- 

45 ating model is essentially the same as in figure 2 but the 
architecture in figure 3 does not suffer from the same 
disadvantages. On the other hand, the single-box solu- 
tion 102 gives restricted flexibility and scalability since 
the home agent component and the VPN components 

so are always co-located. The fact that both components 
must be provided by the same vendor may also be a 
disadvantage. Many enterprises have already made ex- 
isting investments in either Mobile IP or VPN compo- 
nents. An integrated single-box solution prevents these 

55 companies from leveraging their previous investments. 
[0030] The architecture shown in figure 4 is based on 
the same principles as in figure 3 but it is implemented 
as a multi-box solution. The single-box solution is here 
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replaced by three components; the inside home agent 
102, the VPN gateway 104 and a proxy agent 108. The 
proxy agent is located in a de-militarized zone 106 out- 
side the secure domain and it is basically the equivalent 
of a home agent and a mobile node implemented in the 
same box. Its role is to be an intermediate relay for sig- 
naling and packet forwarding between the real mobile 
node 103 and the inside home agent 102. The rationale 
of the proxy agent is to handle signaling and packet for- 
warding in a secure way by working in harmony with the 
VPN gateway and the internal home agent. The proxy 
agent must be located in a DMZ since embracingfirewall 
policies must protect it. The proxy agent 108 is drawn 
partly in solid gray and partly in a hatched pattern to in- 
dicate that the inside home agent 1 02 trust it yet at the 
same time the proxy agent is accessible from outside 
without using the VPN solution. 
[0031] Even if the architecture shown in figure 4 is an 
improvement over the one shown in figure 3, giving in- 
creased flexibility and also accommodating a multi-ven- 
dor environment, the architecture of figure 4 also has 
some unfortunate characteristics. 
[0032] First, the proxy agent 1 08 requires specific pro- 
tocol considerations as well as network design consid- 
erations. This is much due to the fact that both the VPN 
gateway 104 and the proxy agent 108 are involved in 
routing the same set of mobile node addresses, with the 
risk of conflicts or design flaws. These boxes must also 
be located on the same subnet, thus reducing deploy- 
ment flexibility. The fundamental idea is to ensure that 
both signaling and data packets between the mobile 
node 103 and the actual home agent 102 will always 
traverse the proxy agent 1 08. In the end, the proxy agent 
is a vulnerable component since the security of the ar- 
chitecture in figure 4 depends totally on a correct setup. 
On one hand, the proxy agent, the VPN gateway and 
the home agent must all work in harmony. On the other 
hand, the proxy agent must be protected by the firewall. 
In this complex environment any mis-configuration rep- 
resent a security risk. 

[0033] Secondly, the proxy agent is a novel compo- 
nent that must be developed by the industry before the 
architecture shown in figure 4 is ready for deployment. 
Moreover, extra capabilities are required both from the 
VPN gateway, the home agent and the mobile node that 
are either beyond the base protocols standard or be- 
yond what is currently the state-of-art in the industry. Ac- 
commodating these changes will take time too. In sum, 
the architecture of figure 4 demands an effort from the 
whole industry before it is ready for deployment. 
[0034] Finally, according to Amdahl's law [1 1 ] the per- 
formance of the proxy agent 1 08 and the VPN gateway 
104 is linked. Increasing the performance of the total 
system requires as carefully balanced upgrade of the 
performance of its constituent's components. The inner 
home agent 1 02 and the proxy agent 1 08 are also linked 
since the proxy is designed to be the primary handling 
agent. A mobile node on the inside will attempt a regis- 
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tration with the proxy agent first, and only subsequently 
register with the inner home agent 102 if the proxy tells 
the mobile node to do so. This makes the proxy agent 
a critical component reducing the overall reliability of the 
5 total system. If the proxy agent becomes unavailable the 
whole system breaks down. 

State-of-art client software 

10 [0035] The current art of client software, including 
both the Mobile IP part and the VPN part, has impact on 
how a combined architecture can be realized. Taking a 
Mobile IP client vendor like Birdstep as the starting point, 
figure 5 and figure 6 show the prevailing implementation 

15 principles. These principles apply for today's state-of- 
art terminals like laptops and PDAs, running a state-of- 
art operating system like Microsoft Windows. These ter- 
minals and operating systems make a distinction be- 
tween user space 119 and kernel space 120. User ap- 

20 plications 121 run in user space. This is in contrast to 
key network components like a TCP/IP stack 118, driv- 
ers for LAN/WLAN adapters 1 1 0 or drivers for PPP dial- 
connection 111 that come as a native part of the oper- 
ating system in kernel space. Note finally that the prin- 

25 ciples embodied in figure 5 and figure 6 assumes the 
overlaid VPN model from figure 2, 3 and 4. Hence, the 
VPN driver, 117 horizontal, level is above the Mobile IP 
driver level, 115 horizontal, in kernel space. The exten- 
sions of these software components into user space, 

30 115 vertical, 117 vertical, represent the corresponding 
daemon parts. 

[0036] The difference between figure 5 and 6 is how 
the VPN software is implemented. As suggested by fig- 
ure 5, some vendors add a virtual VPN adapter 112 to 

35 the client software to host locally the address from the 
secure domain that is associated with the VPN connec- 
tion. A virtual VPN adapter is just like any other adapter 
to the overlaying driver levels. However, since there is 
no physical connection on a virtual VPN adapter the 

40 VPN software 117 must take care of routing traffic to one 
of the physical adapters 110, 111 . As suggested by fig- 
ure 6 other VPN client implementations does not have 
a virtual VPN adapter. These solutions will rather main- 
tain in the VPN gateway the association between a par- 

45 ticularVPN connection and an address from the secure 
domain. The gateway will in this case also effectively 
perform a Network Address Translation (NAT) opera- 
tion. 

[0037] In either case, the Mobile IP client software 1 1 5 
50 uses its own virtual mobility adapter 1 1 2 to maintain the 
invariable Mobile IP address. The user space part of the 
Mobile IP software, 115 vertical part, is a daemon that 
determines what physical adapter represents the cur- 
rently optimal connection. The role of the Mobile IP driv- 
55 er part, 1 1 5 horizontal part, is to shift packet traffic ac- 
cordingly between the virtual mobility adapter and the 
currently active physical adapter. The dashed vertical 
lines in figure 5 and figure 6 suggest how the different 
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adapter instances are visible at all levels all the way up 
to the user application. The solid vertical line parts that 
connect the different levels in kernel space represent 
the packet shifting. Hence, these lines show how pack- 
ets actually flow. Traffic to/from the user application are 
associated with the VPN adapter if one exists. 
[0038] Otherwise, the traffic is associated with the 
Mobility adapter. In the former case the VPN daemon 
will perform the required packet shifting between the 
VPN adapter and the Mobility adapter. 
[0039] Client software for the architecture shown in 
figure 2, which is the opposite of the overlaid VPN ar- 
chitecture from figure 1 , is realized along similar lines 
as those shown in figure 5 and figure 6. First, the drivers 
115 and 117 must swap position in the stack. Second, 
packet shifting is less of an issue since the Mobile IP 
client will then always send its traffic over what is defined 
to be the default route by the VPN solution. 
[0040] Please note that the hybrid architecture shown 
in figure 4 effectively assumes that the Mobile IP ad- 
dress and the inside VPN address associated with a mo- 
bile node 103 is the same address. For this reason, the 
hybrid architecture will only work if the VPN client does 
not have its own virtual adapter. A VPN client using a 
virtual VPN adapter will lead to an address conflict with 
the virtual mobility adapter used by Mobile IP client. 
[0041] There are two classes among the state-of-art 
VPN solutions today regarding the interface seen by the 
user. Some vendors support a background-monitoring 
model in which the VPN client is resident and always 
ready for action. Any attempt to send traffic to what is 
defined to be the secure domain will automatically lead 
to encryption. Request for user authentication pops up 
automatically whenever needed. Other vendors depend 
on an explicit dial-type model in which the user himself 
must establish the VPN tunnel when communication 
with the secure domain is required. Some vendors sup- 
port both operating models. Note also that most vendors 
support both full-tunnelling and split-tunnelling configu- 
rations in their VPN solutions. In the former case all traf- 
fic will be sent via the secure domain even if it destined 
for an outside location. With split-tunnelling traffic to out- 
side locations can be sent directly from the mobile node 
when it is itself outside. 

[0042] Note finally that a Mobile IP clientcan workwith 
overlaid VPN solutions both in split-tunnelling and full- 
tunnelling mode. In the latter case the only traffic that is 
allowed to bypass the security solution is the Mobile IP 
signalling protocols. 

Rationale of invention 

[0043] The architecture in figure 4 represents state- 
of-art for seamless IP mobility across a security bound- 
ary today. The fact that the Mobile IP system works 
across the security boundary in parallel with the VPN 
gateway is unfortunate, however. The proxy agent rep- 
resents a vulnerable component that must be carefully 


designed and deployed in harmony with the VPN gate- 
way, the inside home agent and the embracing firewall. 
[0044] The invention described in this document has 
its origin as a better approach than the architecture 

5 shown in figure 4 to the same problem. The proposed 
method combines IP mobility and IP security technolo- 
gies in novel way to solve the problem more generally. 
The key to the invention is to use independent IP mobil- 
ity systems at each side of the security boundary rather 

10 than one system spanning the boundary. The two mo- 
bility systems are in turn cleanly separated by the inter- 
mediate IP security solution. The role of the inner mo- 
bility system (running inside the security domain of the 
user) is to make user applications transparent to net- 

15 work changes internally. The role of the outer mobility 
system is to make the remote access security solution 
transparent to network changes externally. Together the 
two mobility systems and the remote access security so- 
lution facilitate seamless IP mobility also across the se- 

20 curity boundary. 

[0045] As previously pointed out the architecture from 
figure 4 suffers from the fact that the VPN solution and 
the Mobile IP system are closely interlinked in various 
aspects. In the end, this is all due to the fact that both 

25 parts operate in the same address domain and that they 
are involved in routing of the same set of mobile node 
addresses. The novelty of the proposed method is to 
make a split at this point by using a different set of ad- 
dresses for mobility handling on each side of the security 

30 boundary. Since each of the three constituent parts op- 
erates in separate address domains their components 
can be deployed at any location within each domain. 
This is in contrast to the architecture shown in figure 4. 
[0046] The invention represents a best-of-breed ap- 

35 proach including the equivalent of both architectures 
shown in figure 1 and figure 2 at the same time. The 
gain of making a clean separation of mobility and secu- 
rity is a method that is more versatile and applicable in 
a wider scope. The proposed method Is client-centric 

40 rather than network-centric. A client-centric approach 
requires no changes in the existing infrastructure except 
the introduction of a new mobility system. Since this sec- 
ond system is standards based anyway, the client-cen- 
tric approach is easier and faster to deploy than a more 

45 involved network-centric approach. The method has 
less side-effects and less stringent deployment require- 
ments than the alternatives known today. The scalability 
is also better since there are no implicit dependencies. 
Each system is deployed individually and can scale (and 

so perform) independently as required. The reliability of the 
combined architecture is also better than the architec- 
ture from figure 4 since there are no dependencies be- 
tween the parts. In particular, the inner system is fully 
operational even if the outer system and the security 

55 gateway components are temporarily unavailable. 
Moreover, the inner system will still be accessible from 
outside even if the outer system is temporarily down. 
[0047] The invention provides secure and seamless 
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IP mobility in any domain with independent choice of IP 
mobility and security technologies. The method does 
not require any changes (adaptations nor extensions) 
to any I P mobility or security technology beyond existing 
or upcoming standards. Nor does it require any changes 
to existing network design and infrastructure compo- 
nents. The mobility client software is the only compo- 
nent that is affected, hence being the enabling compo- 
nent. The method applies both forthe current IPv4 fam- 
ily of standards as well as the forthcoming IPv6 family 
of standards. The method applies in particular for the 
Mobile IP and IPSec VPN standards but is not restricted 
to these technologies. The method is applicable for any 
IP mobility and IP security protocols as long as they are 
based on the same few underlying principles. 
[0048] In the following, the invention will be exp- 
plained with reference to the accompanying drawings, 
wherein: 

fig. 7 is a schematic representation of an example 
of a Mobile IP solution according to the present in- 
vention, 

fig.8 is a schematic representation of another ex- 
ample of a Mobile IP solution according to the 
present invention, 

fig. 9 is a schematic layer model representation of 
an example of a client, and network adapter, ar- 
rangement according to the present invention in a 
Mobile IP data terminal, 

fig.1 0 is a schematic layer model representation of 
another example of a client, and network adapter, 
arrangement according to the present invention in 
a Mobile IP data terminal, 

fig.11 is a schematic layer model representation of 
yet another example of a client, and network adapt- 
er, arrangement according to the present invention 
in a Mobile IP data terminal, 

fig. 1 2 is a flow chart representation of the operation 
of an example of a client arrangement according to 
the present invention for a Mobile IP data terminal, 

fig. 13 is a schematic representation of an example 
of address arrangemets in a Mobile IP solution ac- 
cording to the present invention, 

fig. 14 is a schematic representation of an example 
of a data packet encapsulation arrangement in Mo- 
bile IP solution according to the present invention, 

fig. 15 is a schematic representation of an example 
of a data packet decapsulation arrangement In Mo- 
bile IP solution according to the present invention, 
and 


fig. 1 6 is a schematic illustration of an example of a 
deployment of multiple Mobile IP home agents 
along the edges of an outer network. 

5 [0049] First to follow is a description of the method an 
arrangement of the invention. 
[0050] The general method is best described when 
casted in a more specific setting. Hence, this section de- 
scribes the invention assuming that Mobile IP is used 

10 for mobility handling and that an IPSec VPN solution is 
used for remote access to the secure domain. The gen- 
erality and extendibility of the method is described in a 
subsequent section. 

[0051] As suggested by figure 7, the method is based 

is on the combined use of independent Mobile IP systems 
in the secure domain 105 and insecure domain 107, re- 
spectively. The gray shaded home agent, 130 gray, in- 
side the secure domain represents the inner system. 
The hatched home agent, 102 hatched, outside the se- 

20 cure domain represents the outer system. The enabling 
component of the method is the Mobile IP client software 
running on the user device that can operate with both 
Mobile IP systems simultaneously. The dual capability 
is indicated by the partly solid gray and partly in a 

25 hatched pattern on the mobile node 1 03. 

[0052] It is assumed that the user's ordinary VPN so- 
lution is in control of all access to the secure home do- 
main. In particular, operation of the inner Mobile IP sys- 
tem takes place over the VPN solution; ie. the mobile IP 

30 tunnel, 124 thin, forthe inner system is embraced by the 
VPN tunnel 123. This corresponds to the architecture 
shown in figure 2. Operation of the outer Mobile IP sys- 
tem is in contrast according to the architecture shown 
in figure 1 ; ie. the VPN tunnel 123 is embraced by the 

35 Mobile IP tunnel, 124 thick, of the outer system. Hence, 
the proposed method is a best-of-breed approach in- 
cluding both legacy architectures at the same time. This 
is reflected by the fact that there are three levels of tun- 
nels involved when the mobile node connects from the 

40 outside. The native user traffic 125 is in the end carried 
by the Mobile IP tunnel 124 of the inner system. 
[0053] The role of the inner Mobile IP system is to 
make user applications transparent to network and ad- 
dress changes inside the secure domain. Note that this 
includes the transition case when the mobile node 
moves from the inside to the outside. Then a VPN tunnel 
will be established that is basically a prolonged arm of 
the secure domain . A key feature of the method is to use 
the internal address that is associated with the VPN tun- 

50 nell 123 as the care-of-address in the binding list of the 
inner home agent, 130 gray. This inner care-of-address 
will not change as long as the mobile node 1 03 connects 
from the outside via the VPN tunnel. At this point the 
outer Mobile IP system becomes important. The role of 

55 the outside system is to make the VPN tunnel itself 
transparent to network and address changes on the out- 
side. In sum, the two Mobile IP systems take different 
roles but works naturally together isolated by the inter- 
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mediate VPN solution. 

[0054] The inner system, 130 gray, is always in use 
for a mobile node. The outer system, 1 02 hatched, is in 
use only when the mobile node is outside. In this case 
the operation of the inner system becomes trivial for the 5 
reason just explained. Moreover, the inner system will 
always operate in co-located mode when the mobile 
node 103 is on the outside. Otherwise, both Mobile IP . 
systems can operate both in co-located mode and in for- 
eign agent mode. Foreign agents that are deployed on « 
the inside will be used by the inner system. Foreign 
agents that are deployed on the outside will be used by 
the outer system. 

[0055] The issue of reverse tunneling for the two sys- 
tems is discussed in a subsequent section on address- « 
ing details. 

[0056] There are no specific requirements on the ad- 
dress range that is used for mobile nodes in the inner 
system. Any address range can also be use for the out- 
side system. The use of mobile node addresses in the 20 
outer system is of a more dynamic nature, though, since 
this system is only in use as long as the mobile node 
connects from the outside. In this period the terminal is 
actually equipped with two mobile node addresses, one 
from each system. Whereas the mobile node address 25 
from the inner system is permanent during operation, 
the mobile node address from the outer system can be 
allocated dynamically as needed. The only requirement 
is that these two addresses must never be the same. If 
private addresses are used for the outside system re- so 
verse tunneling must be used as always. 
[0057] Any subnet inside the secure domain can be 
designated as the home network for the inner Mobile IP 
system. A designated home network for the outer sys- 
tem is more of an open issue. If the outer home agent 35 
is deployed in the DMZ 1 06 of an enterprise, the system 
will usually run with a virtual home network. It is very 
uncommon to allow hosts to connect directly to the DMZ. 
An interesting opportunity arises if the enterprise has 
already a WLAN on its premises connected to the fire- *o 
wall on a separate segment. Such a configuration is 
common today since a WLAN is insecure and should 
not be connected directly inside the secure domain of 
the enterprise. Rather, the VPN solution is used to con- 
nect over the WLAN from outside. As suggested by the 
figure B the WLAN 109 will in this case be the perfect 
place for the outer home agent, 102 hatched. The im- 
portant observation is that any mobile node 103 con- 
necting to this network will effectively be transparent to 
the outer Mobile IP system since it is the designated out- 50 
er home. As suggested by figure 8 a mobile node will in 
this case connect to the inner system over the VPN so- 
lution only. Saving the overhead of the embracing outer 
tunnel 124 contributes to better performance, which is 
particularly important in this case since it is reasonable ss 
to expect that many users will spend a large portion of 
their working day in this wireless environment. 
[0058] To summarize this section, considerthe follow- 
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ing list of the key characteristics of the two mobile IP 
systems under various conditions 

Inner Mobile IP system: 

• Is always in use 

• Physical home network on internal subnet 

• User's application binds to the home address 
of this system, hence application transparency 
and seamless operation, both internally and 
across the security boundary 

Mobile node is inside: 

o The VPN solution is turned off. 

o Operation in the standard way (ac- 
cording to Mobile IP) using the inner 
home agent 

Mobile node outside 

o The VPN solution is turned on 

o Signalling messages are exchanged 
with the inner home agent over the 
VPN tunnel. 

o care-of-address in binding list of the in- 
ner home agent is always the address 
of the Mobile node's address from the 
secure domain (maintained by the 
VPN solution). 

o Operation of inner system becomes 
trivial 

Outer Mobile IP system 

• Is used as required 

• Physical home on externally connected enter- 
prise WLAN 

Mobile node is inside 

o The outer system is not in use 

Mobile node outside 

o Outer system is required 
o Binding list of outer home agent holds 
the address of the mobile node's cur- 
rent external address 
o The VPN tunnel binds to the home ad- 
dress of the outer system, hence VPN 
transparency 

[0059] In the following, a Dual Client implementation 
will be explained. 

[0060] The enabling component of the invention is 
Mobile IP client software that can operate with two in- 
dependent Mobile IP systems simultaneously, and in 
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such a way that these systems are separated by an or- 
dinary VPN solution. In the following this kind of client 
will be referred to as a dual mobility client. This is in con- 
trast to a singular mobility client that is otherwise state- 
of-art today. When executed in a computer device of a 
mobile node, the software computer product of the in- 
vention establishes the arrangement of the Invention. 
When executed in a computer device of a mobile node, 
the software computer product of the invention effects 
the execution of the method of the invention. 
[0061 ] Implementation of a dual client on a device run- 
ning a state-of-art operating system (like members of 
the Microsoft Windows family) is based on the same im- 
plementation principles as previously outlined in figure 
5 and figure 6. Two enhancements are then made; first, 
another virtual mobility adapter is added to host the in- 
variable address of the second Mobile I P systems. Next, 
a new Mobile IP driver level is included above the VPN 
driver level. The resulting kernel-space architecture is 
shown in figure 9, assuming that the VPN client uses its 
own virtual VPN adapter 114. The new upper Mobile IP 
driver 11 6 together with the new virtual mobility adapter, 
now called the intranet adapter 113 accounts for the in- 
ner Mobile IP system. The lower Mobile IP driver 115 
together with the original virtual mobility adapter 112 ac- 
counts for the outer system. The intermediate VPN driv- 
er level 117 isolates the two systems and takes care of 
all security in the ordinary way. The arrows shown in fig- 
ure 9 suggest how traffic is shifted on its way through 
the driver stack. This particular figure corresponds to the 
case when the mobile node is outside the secure do- 
main and both systems are in use. 
[0062] The seamless operation results from the fact 
that the application level above the upper Mobile IP driv- 
er 1 1 6 relates to the intranet adapter 1 1 3 that will always 
be present and available as a transport end-point. 
[0063] Figure 1 0 shows the kernel-space architecture 
of a dual Mobile IP client when the intermediate VPN 
solution does not have its own virtual VPN adapter. 
Again it represents the case when the mobile node is 
outside the secure domain . The sequence of arrows sig- 
nifying packet shifting is slightty different due to the 
missing virtual VPN adapter. 
[0064] As already pointed out the inner system is al- 
ways in use whereas the outer system is in use only 
when the mobile node is outside the secure domain. 
Moreover, the operation of the inner system is trivial 
when the mobile node is on the outside since the inner 
care-of-address is then always the intranet address as- 
sociated with the VPN connection and will not change. 
When the mobile node is inside the secure domain the 
operation of the inner system becomes more complex 
as it must handle true network handovers and address 
changes. This complexity is the same as for the outer 
system when it is in use. Figure 11 shows the resulting 
kernel-space architecture that applies when the mobile 
node is on the inside. The components 116, 117, 112 
become transparent or idle in this case as explained be- 


low. 

[0065] The key point regarding implementation is that 
the upper M obile IP driver 1 1 6 can be disabled when the 
mobile node is on the inside. At the same time the lower 
5 Mobile IP driver starts supporting the inner system rath- 
er than the outer system. Hence, the implementation of 
the dual client rests on the fact that there is a context 
switch in the operating environment of the lower Mobile 
IP driver 1 1 5. A part of th is context shift is to let the lower 
10 driver start operating on the intranet adapter 1 1 3 rather 
than the mobility adapter 112. As a consequence, true 
mobility handling with packet shifting to physical adapt- 
ers is only implemented in the lower Mobility driver. This 
driver is used for the inner or the outer system, depend- 
15 ing on if the mobile node is on the inside or on the out- 
side. In the latter case, the upper Mobile IP driver starts 
it operation to maintain the inner system until the mobile 
node returns to the secure domain. For reasons already 
explained, the complexity of this driver is trivial com- 
20 pared to the lower driver. 

[0066] The VPN solution 117 is also turned off when 
the mobile node is on the inside. Any virtual VPN adapt- 
er used by the VPN solution will then disappear from the 
operating environment. Hence, the kernel-space archi- 
es tecture will be the same regardless of the kind of VPN 
solution being used. 

[0067] The preceding description is based on the as- 
sumption that the dual client is implemented on a "open 
platform" device having a modular operating system en- 

30 vironment comprising both user space and kernel 
space. Moreover, the concept of a driver and an adapter 
is central to the discussion. Other devices, and in par- 
ticular embedded devices, may have operating environ- 
ments that are very different. If there is no modular ar- 

35 chitecture the dual client must be implemented as a 
monolithic system. Depending on the capabilities of the 
host device such a system can be implemented in either 
userspace or kernel space. In some cases It might even 
be included as an integral part of the host operating sys- 

40 tern and the default run-time environment. 

[0068] The flow-chart in figure 12 represents a more 
abstract view of the traffic-flow principles that have just 
been outlined in a specific setting. The general princi- 
ples must underpin any implementation of a dual client, 

45 regardless of the specific characteristics of the particular 
host device. The flow-chart assumes that neither ordi- 
nary reverse tunnelling nor NAT traversal is needed 
when the Mobile IP client connects directly to the inner 
system. The role of reverse tunnelling is otherwise dis- 

50 cussed in a subsequent section on addressing. 

[0069] In the following, domain detection will be ex- 
plained. 

[0070] The principles outlined in the previous section 
comprise the traffic flow part of a dual client implemen- 
55 tation. The control part (normally implemented in a dae- 
mon) must be enhanced accordingly to also include sup- 
port for a second mobile IP system. Moreover, this ca- 
pability must be made optional so that it can be activated 
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as required (for reasons already explained). The final 
piece is to let the daemon initiate the context-switch, de- 
pending on if the mobile node is inside or outside the 
secure domain. This is based on a domain detection 
mechanism that is carefully designed. Since this deci- 
sion in the end governs the on/off status of the VPN cli- 
ent, It is paramount that the detection algorithm is relia- 
ble and cannot be compromised. At the same time It is 
important that the decision can be made quickly to re- 
duce the performance penalty when the mobile node 
moves between networks, and in particular when It 
moves across the security domain. 
[0071] The domain detection mechanism is con- 
cerned about the follow two transitions: 

• When the mobile node was already connected from 
outside and a new inside connection is recognized 
(or suspected). 

• When the mobile node was already connected at 
the inside and a new outside connection is recog- 
nized (or suspected). 

In either case, the new connection can be over the same 
adapter as the previous connection or it can be over a 
different adapter. 

[0072] In the end, the only reliable evidence that the 
mobile node is connected to either of the two domains 
via one of its physical adapters is when a registration 
with the appropriate home agent succeeds over that 
adapter. The reliability rests on the security associations 
between the home agent(s) and the mobile node that is 
already a part of the Mobile IP system(s). The brute- 
force approach is to always attempt registrations with 
both agents whenever domain detection is required. 
The downside of this approach is poor handover per- 
formance, in particular across the security boundary. On 
one hand this is because registrations may not get 
through to the appropriate home agent when issued 
from the opposite side of the security boundary. Han- 
dling pending registrations contribute to the complexity 
of the operation in the daemon and should be avoided 
whenever possible. On the other side, if a registration 
succeeds domain detection is complete but the active 
adapter has also then changed. The latter is really an 
undesired side-effect if the adapter turns out not to be 
the optimal. The recent registration will then be overrid- 
den immediately resulting in a performance penalty. 
[0073] The need here is to have a reliable home agent 
service discovery mechanism that is not linked to a real 
registration. A spin-off activity of this invention is to try 
to standardize such a mechanism. It the meantime the 
performance-degrading effects can be overcome by first 
making conjectures about location that are based on 
less reliable but faster domain detection mechanisms 
with no side-effects. Operation can then proceed more 
quickly with a fairly high probability that the conjecture 
in the end turns out to be correct. If the initial conjecture 
was wrong, the brute-force approach will in the end lead 


to the correct conclusion. The less reliable domain de- 
tection mechanisms that are covered by the invention 
are as follows: 

5 • Compare observed IP address information with pre- 
configured address ranges used inside the secure 
domain 

• Utilize information In control messages like ICMP 
(including agent advertisements) that is a constitu- 
te) ent part of the normal traffic flow on the network. 

• Perform an unreliable home agent detection by 
sending a registration with deliberately wrong secu- 
rity association. This will effectively "smoke out" any 
home agent if it is reachable without actually per- 

15 forming a registration. 

• Utilize network context history that is recorded and 
stored during operation. Such information is collect- 
ed for foreign agents, default gateways, WLAN ac- 
cess points, etc. using their layer two identifiers (like 

20 MAC address) as the basis for indexing. 

[0074] In the following, addressing details will be ex- 
palined. 

[0075] Three different parts of the proposed architec- 
ts ture in figure 7, ie. the inner Mobile IP system, the inter- 
mediate VPN solution and the outer Mobile IP system, 
result in three levels of addresses and tunnel encapsu- 
lations. This can be hard to understand until it is explic- 
itly spelled out. Equipped with an overall description of 
30 the method together with the principles for a dual client 
implementation, this section describes the details re- 
garding addressing. 

[0076] Figure 13 shows the various components in- 
volved together with the address designators that are 
35 used for the different components. Note that the mobile 
node 103 is equipped with four different addresses, cor- 
responding to the two mobile IP systems, 130 gray and 
1 02 hatched, the VPN solution 1 04 and finally the phys- 
ical address of the network to which the mobile node is 
40 currently connected 1 07 in this case). The V-address on 
the mobile node suggests that there is a local VPN 
adapter in this case. If there is no local VPN adapter the 
V-address will not exist locally. The T-addresses for the 
outer home agent and the VPN gateway refers to inter- 
ns faces that are reachable from the outside. 

[0077] The use of reverse tunnelling for each of the 
two systems is closely related to addressing. Reverse 
tunneling might be required for the inner system de- 
pending on the characteristics of the VPN solution. VPN 
so solutions using a virtual VPN adapter may enforce strict 
filtering policies, either on the client side, or on the gate- 
way side that effectively will prevent any traffic over the 
VPN connection with a source address that is different 
from the V-address allocated to the remote connection. 
55 Employing reverse tunneling will ensure that the topo- 
logical^ correct source address is used for reverse traf- 
fic. This is nothing different from using reverse tunneling 
to overcome ingress filtering in the outside domain. 
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[0078] For VPN solutions not using a virtual VPN 
adapter there is a similar rationale for using reverse tun- 
neling but this time only to overcome any actions taken 
on the client side. The VPN gateway should not expect 
any particular source address since it has not distributed 
any to the local device. Many of these gateways will in- 
stead perform a NAT operation to convert between a 
topological^ valid address on the inside (the equivalent 
of a V-address) and the actual address used for the con- 
nection on the outside (the T-address will be used). In 
this case the care-of-address registered in the inner 
home agent (ie. the T-address) may become topologi- 
cal^ invalid if it is not routable inside the secure domain. 
To overcome this problem NAT traversal of Mobile IP 
[10] must be supported by the inner system. A specific 
form of tunneling is then used for the inner system, both 
in the forward and the reverse direction. This is nothing 
different from using the same mechanism in the outer 
system to overcome NAT devices in the outside domain. 
[0079] Except from the reasons just explained re- 
verse tunneling should in general not be required for the 
inner system when connected on the inside. The as- 
sumption is that S-addresses are accommodated as 
valid source addresses on any inside network and that 
there are no NAT devices on the inside. Mobile nodes 
on the inside can send traffic directly in the reverse di- 
rection. The need for reverse tunneling in the outer sys- 
tem is "as usual". It is required either if private mobile 
node addresses are used or if ingress filtering is being 
performed on any local access. 
[0080] Consider now the sequence of steps taking 
place in an externally attached mobile node for a packet 
that is destined for a corresponding node inside the en- 
terprise. This is shown in figure 1 4 also suggesting what 
parts taking place at the different levels. For simplicity, 
it is assumed that the correct registrations have already 
been completed both for the inner and the outer Mobile 
IP systems. Assumingthat reverse tunnelling is required 
for the outer system, the packet that eventually leaves 
the mobile node (over the active adapter) is destined for 
the outer home agent. The structure of this packet 
shows clearly the outer Mobile IP reverse tunnel encap- 
sulation, then the VPN tunnel encapsulation, and finally 
the inner Mobile IP reverse tunnel encapsulation. The 
reason for the inner reverse tunnel is to ensure a correct 
topological source address corresponding to the VPN 
address. 

[0081] Consider next the sequence of steps that takes 
place in the outer home agent, the VPN gateway and 
eventually the inner home agent as the same packet 
traverses these components on its way to the corre- 
sponding node inside the secure domain. This is shown 
in figure 15. 

[0082] If a VPN solution without a VPN adapter is 
used, there are minor changes to the picture. The V-ad- 
dress will then not exist in the mobile node and the T 
address is temporarily used in its place. Normally, when 
the packet arrives at the VPN gateway the correct V- 


address will replace the T-address, effectively perform- 
ing a NAT operation. For this reason a UDP based re- 
verse tunnelling might need to be inserted. This is dis- 
cussed in more detailed later. 

5 [0083] Packets originating from a corresponding node 
and destined for an outside mobile node follows the op- 
posite path of what has just been described. The result- 
ing figure is not shown explicitly but follows directly from 
considering figure 14 and figure 15 in revers and at the 

10 same time swap the addresses in all source/destination 
pairs. The reverse tunnel encapsulations from figure 14 
and 15 will then be replaced by corresponding forward 
tunnel encapsulation from the home agents, of course. 
[0084] A similar exercise for the packet flow between 

15 a corresponding node and mobile node inside the se- 
cure domain is trivial since it reduces to ordinary Mobile 
IP operation in a single system with no VPN solution in- 
volved. 

[0085] The description of the invention has up to this 

20 point been casted in a specific setting; ie. an enterprise 
deploying its own Mobile IP service in an IPv4 environ- 
ment using an existing IPSec VPN gateway. The pro- 
posed method emerged as a novel solution to this prob- 
lem but has in itself a much wider scope of applicability. 

25 First, the involved technologies and components can be 
replaced by other technologies and components as long 
as the replacements share a few common characteris- 
tics with the components and technologies in the original 
description. Secondly, the method can be applied in 

30 many other deployment scenarios to solve other prob- 
lems than the original one. This section focuses on the 
first aspect. The next section is devoted to describing 
other deployment scenarios of interest. 
[0086] In the end, the proposed method depends only 

35 on a few fundamental and general characteristics: 

• That both mobility systems run over an IP transport 
infrastructure. 

• That both mobility systems are based on a client- 
40 server model in which the server component (aka: 

agent) is the authoritative source for mobility han- 
dling. 

• That the remote access security solution (if any) 
runs over an IP transport infrastructure. 

45 • That the remote access solution is based on a cli- 
ent-server model in which the server component 
enforces the security policy at the domain boundary. 

• That the remote access solution provides a secure 
IP transport facility between the client and the serv- 

so er. 

• That the server component of the security solution 
is able to distinguish between individual remote 
connections. Further, that a unique address is as- 
sociated with each such connection and that this 

55 address is routable from the inside domain. 

• That the terminal device of interest has capabilities 
(hardware and software) facilitating implementation 
of a system with dual client capabilities. 


12 


23 


EP 1 381 202 A2 


24 


[0087] These principles are already embedded In the 
base Mobile IP standards for both IPv4 and IPv6, hence 
it follows that the invention applies also when the base 
standards are accompanied by additional standards ex- 
tending the base protocols. Note in particular that bind- 
ing updates (that is a default part of Mobile IPv6 to sup- 
port routing optimisation) is naturally accommodated by 
the proposed method. The same applies for any (future) 
enhancements and improvements to the family of Mo- 
bile IP standards. As a particularly Important example 
the upcoming standard on NAT traversal using UDP en- 
capsulation [10] is supported. Intact, NAT traversal can 
be supported in each of the two systems individually. 
Likewise, the important upcoming Authentication Au- 
thorisation and Accounting (AAA) protocol extensions 
[12] of Mobile IP are supported in both systems. 
[0088] The principles from the above list are also al- 
ready embedded in the base IPSec standards, again in- 
cluding both IPv4 and IPv6. Consequently, the proposed 
method works with all options, extensions and additions 
included in both IPSec protocol standard families. Note 
in particular that the method works with IPSec both in 
tunnel mode and transport mode if each of those modes 
is otherwise applicable in the particular context. 
[0089] The following (non-exhaustive) list gives some 
additional examples of what is covered by the proposed 
method. 

• Other tunnelling mechanisms than those that are 
currently embodied in the Mobile IP standards. In 
particular, there is a gain for tunnelling header com- 
pression to reduce the overhead imposed by the 
three layer of encapsulations. 

• Other IP mobility protocols than Mobile IP, if they 
comply with the principles from the above list. 

• Other IP security protocols than IPSec, if they com- 
ply with the principles from the above list. In partic- 
ular, the L2TP[8] and PPTP[9] protocols are both 
supported. 

• The trivial "null" case with no security solution at all. 

• Mixed systems using IPv4 and IPv6 in different 
parts (eg. IPv6 inside and IPv4 outside). The only 
assumption is that any of the known I Pv4-IPv6 tran- 
sition methods otherwise apply in the particular con- 
text. Moreover, the mobile node must be equipped 
with a dual-stack solution in this case. 

• Other kind of client devices than laptops, PDAs and 
similar personal terminal devices. In particular, the 
method can be applied when the client side is im- 
plemented as a part of a mobile router that is capa- 
ble of moving a complete network (with multiple us- 
ers) rather than just a single user. 

[0090] In the following, deployments of the method of 
the invention will be explained. 
[0091 ] The first application of the proposed method is 
to solve the known problem of seamless IP mobility 
across an enterprise security boundary in a new and 


more beneficial way. Even if the method emerged as a 
novel solution to this problem it has in itself a much wider 
scope of applicability. In this section two other deploy- 
ment examples are briefly described. These are both so- 

5 lutions to problems that have not yet been addressed or 
solved by the industry. These problems are both conjec- 
tured to become important in the future. 
[0092] Up to this point it has implicitly been assumed 
that both IP mobility systems are run and administrated 

10 by the same entity (the enterprise). The independence 
between the systems opens for a very interesting op- 
portunity though, namely that the systems are operated 
by different administrative entities. An enterprise will it- 
self always be responsible for the inner system since 

15 this system is part of the secure domain. The outer sys- 
tem is different and the enterprise can equally well ex- 
ploit a mobility service from a public network operator. 
The public operator can on his side offer the same serv- 
ice to many enterprises. The business opportunity for 

20 the operator is to deploy home agents along the edges 
of the public network, close to where enterprises have 
their security gateways. An illustration of this idea is 
shown in figure 1 6. The operator can also offer dynamic 
allocation of outer home agent if his service is linked to 

25 an AAA infrastructure. The enterprise user will then al- 
ways use the most optimal agent In the area where his 
security gateway is located. This is a particularly impor- 
tant feature for a user from an advanced enterprise 
since he may then use different security gateways de- 

30 pending on his actual outside location. Distributed and 
redundant security gateway architecture is state-of-art 
today among large enterprises spanning multiple sites 
and countries. In sum, independent operation and ad- 
ministration of the two mobility systems facilitate new 

35 future business models among and across public oper- 
ators and private enterprises. The only requirement is 
to include handling of two separate administrative inter- 
faces in the dual mobility client. 
[0093] Another interesting application of the proposed 

40 method is to build mobility solutions across networks 
with different version of the IP protocol. Today, Mobile 
IPv4 is the most mature technology. Mobile IPv6 is still 
being standardized but is conjecture to become increas- 
ingly important as the transition from IPv4 to IPv6 net- 

45 works otherwise takes place. The situation on the Inter- 
net in the first phase of this transition period will be a 
number of IPv6 network islands immersed in a large sea 
if IPv4 networks. Building a mobility service across 
these network boundaries lends itself naturally to a dual 

so client solution. The on ly assumption is that the terminal 
device comprising the mobile node has dual-stack ar- 
chitecture, le. a device including both a IPv4 and a IPv6 
protocol environment and supporting both protocols at 
the same time. The current commercial implementa- 

55 tions are usually dual stack implementations. The result 
is a transition method where the end-systems can reap 
the benefits of both Mobile IP v6 and Mobile Ipv4 in a 
mixed environment. The transition boundaries can also 
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be security boundaries, of course, as long as the secu- 
rity gateway is also dual-stacked. For an enterprise two 
operational modes can be envisaged. The first opera- 
tional mode where the inner IP mobility system is using 
Mobile IPv4, is applicable for enterprises and other or- 5 
ganizations that would like to maintain their IPv4 based 
system while reaping the benefits of an Mobile IPv6 so- 
lution on the outside. The second operational where the 
inner IP mobility system is Mobile IPv6, is applicablefor 
enterprises or organizations that have migrated to IPv6 10 
but where the core network beyond the secured domain 
is still using the IPv4. 

[0094] Next follows a summary of benefits and char- 
acteristics of the invention. 

[0095] This final section lists the key characteristics w 
of the proposed method. Focus is on the contribution of 
the invention compared to what is otherwise state-of-art 
today. The list covers benefits of the method itself as 
well as how application of the method can be used to 
solve different problems in different circumstances. 20 

• A best-of-breed approach supporting any of the 
well-know architectures represented by figure 
1,2,4. 

• Based on using two simultaneous but truly inde- 25 
pendent mobility systems isolated by an ordinary 
security solution 

• The ordinary security solution is in control of all re- 
mote access to the secure domain, in particular the 
inner mobility system runs via the remote access 30 
solution if the mobile node connects from outside 

• The two systems fulfil different roles; inner system 
is responsible for user application transparency. 
The outer system is responsible for transparency of 
the security solution itself. & 

• The design is open demonstrating independency 
between mobility and security 

• The combined system offers total seamless opera- 
tion on both sides as well as across the security 
boundary. 40 

• Only the client side is affected. A dual mobility client 
is the enabling component. 

• The complexity of the dual client software is not 
much higher than a singular client. First, the second 
mobility system is not always in use. Second, when 45 
it is in use the operation is almost trivial 

• The client-centric approach (as opposed to a net- 
work-centric) facilitates easy, faster and cost-effec- 
tive deployment. 

• No specific network design requirements beyond so 
the extra mobility system. Works with existing net- 
work designs and require no changes to existing in- 
frastructure components. 

• Facilitates multi-vendor deployment with independ- 
ent choice of mobility system and security solutions, ss 
In particular, previous investments can be lever- 
aged. 

• The combined architecture is flexible and scales 


well since each of the three constituent components 
can be deployed individually and scale independ- 
ently as needed. 

• Requires no changes (adaptations nor extensions) 
to any mobility or security technology beyond exist- 
ing or upcoming standards. 

• Based only on a few fundamental principles that are 
already embedded in ail pertinent IPv4 and IPv6 
standards. Hence, method will work with all options, 
extensions and enhancements of these protocols. 

• Method works also with other mobility and security 
protocols as long as they share the same set of ba- 
sic characteristics. 

• The inner and outer mobility systems can be oper- 
ated by different entities; hence they do not need to 
be part of the same administrative domain. 

• The method solves the known problem of seamless 
Mobile IP across an enterprise security boundary in 
a new and better way 

• The method can be used to solve similar problems 
in a much wider scope. This includes new business 
models for IP mobility across public operators and 
private enterprises. 
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Claims 

1. An arrangement in a mobil data communications 
terminal (1 03) for providing mobil IP communication 
via a dual tunnell IP packet data connection be- 
tween a first application (1 21 ) in the mobil data com- 
munications terminal and a second application 

(101) in a second terminal in communication with 
an inner network (105), said inner network directly 
or via a firewall (104) connected with an outer net- 
work (107), wherein an outer mobil IP home agent 

(102) is arranged in the outer network or in a DMZ 
(1 06) associated with the firewall and an inner mobil 
IP home agent (130) is arranged in the inner net- 
wotk, said arrangement comprising: 

a first mobil IP client part (1 1 6) configurable for 
association with the inner mobil IP home agent 
(130), said first mobil IP client part arranged to 
convey data between the first application and 
the second mobil IP client part and to an inner 
tunnell part (123) directed to the inner home 
agent, and 

a second mobil IP client part (11 5) configurable 
for association with the outer mobil IP home 
agent (1 02), said second mobil IP client part ar- 
ranged to convey data between the first mobil 
IP client part and the outer network and to an 
outer tunnell part (124) directed to the outer 
home agent. 

2. Arrangement according to claim 1 , wherein said 
second mobil I P client part further is configurable to 
also convey data between the first application and 
the outer network, and said arrangement further 
comprising a device which, if the terminal obtains 
access via the outer network, is arranged to provide 
a first connection between the first application and 
the first mobil IP client part, a second connection 
between the first mobil IP client part and the second 
mobil IP client part, and a third connection between 
the second mobil IP client part and the outer mobile 
IP home agent, and 

if the terminal obtains access via the inner network, 
is arranged to provide a fourth connection between 
the first application and the second mobil IP client 
part, and a fifth connection between the second mo- 
bil IP client part and the inner mobile IP home agent. 

3. Arrangement according to claim 1 or 2, wherein said 


first mobil IP client part (116) is controllable for ac- 
tivation or deactivation, and said arrangement fur- 
ther comprising a mobil IP detection device: 

5 c. said mobil IP detection device adapted to ac- 

tivate the first mobil IP client part on detection 
of a connection to the inner network (105) and 
a successful! mobil IP registration with the inner 
home agent (130), and 

10 d. said mobil IP detection device adapted to ac- 

tivate the second mobil IP client part on detec- 
tion of a connection to the outer network (107) 
and a successful! mobil IP registration with the 
outer home agent (130). 

15 

4. Arrangement according to claim 1 or2, wherein said 
first mobil IP client part (116) is controllable for ac- 
tivation and deactivation, and that the arrangement 
further comprises a mobil IP detection device ar- 

20 ranged to activate the first mobil IP client part on 
detection of connection to the outer network (107) 
by means of at least one of a detection device se- 
lected from a group comprising: 

25 e. a first monitoring device arranged to deter- 

mine the source IP address of an incoming 
packet and to determine that the address is out- 
side an address range configured for the inner 
network (105), 

30 I a second monitoring device arranged to ana- 

lyze ICMP control messages and arranged to 
determine that an address associated with the 
ICMP control message is outside an address 
range configured for the inner network (105), 

35 g. a third monitoring device arranged to detect 

an outer home agent (102) on transmission of 
a registration message with improper security 
association, and 

h. a fourth monitoring device arranged to com- 
40 pare results from said first and second monitor- 

ing devices with collected history regarding 
MAC and IP addresses to Mobil IP Foreign 
Agents, Default gateways, and WLAN access 
points that indicate that the mobil terminal is op- 
45 erating in the outer network, and 

wherein at least one of said detection devices 
(a,b,c,d) is arranged to indicate that the mobil ter- 
minal (103) is connected to the outer network. 

so 

5. Arrangement according to claim 1 or 2, wherein 
said first mobil IP client part (116) is controllable for 
deactivation, and 

said arrangement further comprising a mobil IP de- 
55 tection device arranged for deactivating the first mo- 
bil IP client part on detection of a connection to the 
outer network (107) by means of at least one of a 
detection device selected from: 
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the outer network or in a DMZ (1 06) associated with 
the firewall arranged between the inner and outer 
network, wherein: 

5 an inner home agent (130) is arranged in the 

inner network, and 

said inner home agent is configurable for asso- 
ciation with a first mobil IP client part (116) op- 
erable in the mobii data communications termi- 
10 nal, and said outer home agent is configurable 

for association with a second mobii IP client 
part (1 1 5) operable in the mobil data communi- 
cations terminal, 

said first mobii IP client part being arranged to 
15 convey data between said first application and 

said other mobil IP client part and to an inner 
tunnell part (123) directed to the inner home 
agent, and 

said second mobil IP client part being arranged 
20 to convey data between said first mobil IP client 


e. a first monitoring device arranged to deter- 
mine the source IP address of an incoming 
packet and arranged for detecting that the ad- 
dress is inside an address range figured for the 
inner network (105), 

f. a second monitoring device arranged to ana- 
lyze ICMP controil messages and arranged to 
detect that an address associated with the IC- 
MP controil message is inside an address 
range configured for the inner network (1 05), 

g. a third monitoring device arranged to detect 
an inner home agent (130) on transmission of 
a registration message with incorrect security 
association, and 

h. a fourth monitoring device arranged to detect 
inconsistances in results from the first, the sec- 
ond and the third monitoring devices and col- 
lected history regarding MAC and IP addresses 
to Mobil IP Foreign Agents, Default Gateways, 
and WLAN access points that indicate that the 
mobil terminal is operating in the inner network 
(105), and 


wherein at least one of said detection devices (a,b, 
c,d) is arranged to indicate that the mobil terminal 25 
(103) is connected to the inner network. 

6. Arrangement according to any one of the previous 
claims, wherein said arrangement further compris- 
es, 30 
a third security client part interposed between the 
first and second mobil IP client parts and configura- 
ble for via a security arrangement arranged be- 
tween said inner and outer networks establishing a 
secure connection with the inner network. 35 

7. A mobil IP terminal, wherein said mobil IP terminal 
comprises an arrangement according to any one of 
the previous claims. 

40 

8. A computer program product comprising a data car- 
rier having thereon a computer program code load- 
able and executable in a mobil IP data communica- 
tions terminal, wherein said computer program 
code when loaded and executed in the mobil I P data 45 
communications terminal effects the establishment 

of an arrangement as recited in any one of claims 
1 through 6. 

9. An information technology (IT) system for providing 50 
a packet data connection between a first application 
(121 ) operable in a mobil data communications ter- 
minal (103) and a second application (101) opera- 
ble in a second terminal in an inner network (105) 
protected by a firewall (1 04), said system arranged 55 
for communication by means of mobil IP with a sys- 
tem comprising the inner network, an outer network 
(107) and an outer home agent (102) arranged in 


part and said outer network and to an outer tun- 
nell part (124) directed to said outer home 
agent. 

10. A data communications system for providing a 
packet data connection between a first application 
operable in a mobil data communications terminal 
(103) and a second application (101) operable in a 
second terminal connected to an inner network 
(1 05) protected by a firewall (1 04), said system ar- 
ranged for communication by means of mobil IP via 
a system comprising the inner network, an outer 
network (107) and an outer home agent (102) ar- 
ranged in said outer network or in a DMZ (106) as- 
sociated with the firewall (104) being arranged be- 
tween the inner and outer networks, wherein: 

an inner home agent (130) is arranged in the 
inner network, and 

said mobil data communications terminal in- 
cluding: 

c. a first mobil IP client part (116) config- 
urable for association with said inner mobii 
IP home agent (130), said first mobil IP cli- 
ent part arranged to convey data between 
said first application and said second mobil 
IP client part and to an inner tunnell part 
(123) directed to said inner home agent, 
and 

d. a second mobil IP client part (115) con- 
figurable for association with said outer 
mobil IP home agent (102), said second 
mobil IP client part being arranged to con- 
vey data between said first mobil IP client 
part and said outer network and to an outer 
tunnell part (124) directed to said outer 
home agent. 
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